문서의 임의 삭제는 제재 대상으로, 문서를 삭제하려면 삭제 토론을 진행해야 합니다. 문서 보기문서 삭제토론 Nintendo 64 (문단 편집) === 리얼리티 코프로세서 === 닌텐도 64는 CPU 이외의 모든 필요한 기능을 리얼리티 코프로세서(RCP)에 담았다. RCP는 칩 하나에 리얼리티 시그널 프로세서(RSP)와 리얼리티 디스플레이 프로세서(RDP)로 구성되어 있다. 리얼리티 시그널 프로세서는 MIPS R4000 기반 128비트 정수 벡터 행렬 연산 장치(SIMD)이며, 16비트 8행렬로 구성된 정수 벡터 행렬을 연산할 수 있었다. 그래픽으로서는 정점, 광원, Z버퍼 같은 지오메트리 연산과 사운드 처리를 위한 DSP 역할을 했다. 사운드는 ADPCM의 경우 최대 24채널 4비트(PCM 16비트를 1/4로 손실 압축) 48kHz, PCM은 100 채널까지 가능하다. 이론적으로는 MP3는 물론이고 100채널 이상의 PCM 사운드를 동시에 처리할 수도 있지만 모든 프로세서 파워를 몰아줘야 할 수 있는 일이고, 무엇보다 롬 팩의 용량 때문에 실현하기 어렵다. 그나마 잘 된 예로서는 샘플링 주파수 11KHz 16비트 모노로 15분 가량의 음악을 담은 [[https://youtu.be/yr0XVj7ZuxY|스타워즈 섀도우 오브 엠파이어]] 같은 게임이 있다. RSP는 MIPS 기반이라는 것에서 알 수 있다시피 그 자체로 하나의 완전한 범용 CPU이다. 당시 기준으로 이전의 콘솔 게임기나 PC 등에서 보통 그래픽 처리를 담당하는 칩은 범용 연산이 아니라 미리 설계된 고정적인 연산만 처리할 수 있는 게 보통이었으나 RSP는 범용 CPU이므로 여기에서 어떤 연산을 할지는 정해주어야 했다. 만약 닌텐도가 미리 ROM에 프로그램을 넣고 RSP가 이 ROM을 읽어서 그 프로그램만 처리하게 했다면 프로그래머 입장에선 그냥 정해진 기능만 있는 칩에 불과했겠지만, 굳이 CPU를 넣어놓고 그렇게 기능을 제한할 이유는 전혀 없으므로 닌텐도는 카트리지 롬에 RSP가 실행할 컴파일된 프로그램을 넣고 이를 RSP가 읽어서 처리하도록 했다. 따라서 만약 프로그래머가 원한다면 RSP가 실행하는 코드를 변경할 수 있었다. 닌텐도는 이를 마이크로코드라고 불렀고 이를 이용해서 RSP의 기능을 다시 프로그래밍할 수 있다. 이것을 잘 활용하면 3D 그래픽이나 2D 그래픽에 특화하거나 시뮬레이션이나 레이싱 게임에 알맞게 연산 속도를 높이는 데 주력할 수 있다. 그러나 이 언어는 개발하기에 끔찍하게 복잡하고(horrendously complex)[* “닌텐도가 깨어나다.”, 더 이코노미스트 1996년 8월 3일자 기사.] 언어가 난해해 [[버그]]와 [[글리치]]가 잘 발생하는데 이것을 [[디버깅]]하기도 어려웠다. 실리콘 그래픽스에서 제공한 표준 마이크로코드 "Fast3D"가 있는데, 개발자들은 이 마이크로코드는 속도 대신 렌더링 정확도에 최적화한 것이기 때문에 성능 저하를 유발해 게임에 적합하지 않다고 지적했다. 닌텐도의 '터보3D'라는 코드는 그래픽을 플레이스테이션 수준으로 떨어트리는 대신 5~60만개의 폴리곤을 낸다고는 알려졌으나 닌텐도는 이를 사용한 게임을 만드는 것을 허가하지 않았다고 한다. 팩터 5, [[레어(회사)|레어]] 같이 몇몇 능력 있는 제작사에서는 맞춤형 마이크로코드를 만들기도 했는데, 인디아나 존스 인퍼널 머신에서는 640×480의 고해상도와 실시간 광원을 사용하는 등 역량을 발휘했지만 결코 바람직한 현상은 아니었다. 또한 이런 개발 난이도 때문에 코나미와 남코에서는 아무리 해도 [[슈퍼 마리오 64]] 같은 것을 만들 수가 없다는 등의 말도 나왔고, 이 때문에 닌텐도가 개발툴이나 노하우를 공개하지 않는다는 등의 루머까지 돌기도 했다. 원하는 대로 프로그래밍할 수 있는 RSP의 특성은 현대의 셰이더와 유사하다고 볼 수 있으나, 문제는 상술했듯이 실제로 개발사가 자신의 게임에 맞춰서 RSP 프로그램까지 새로 개발하는 것은 부실한 개발 문서와 도구 제공으로 인해 지극히 어려웠기 때문에 결국 대부분의 3D 게임은 기본으로 제공되는 Fast3D 계열의 마이크로코드를 그대로 사용했으며 현실적으로 닌텐도 64에서 RSP는 사실상 고정 파이프라인 칩이나 다름 없었다. RDP는 RSP가 계산한 그림을 실제 영상으로 그려내는 렌더링 프로세서 역할을 하고, CPU의 메인 메모리 접근을 지원한다. 최대 640×480의 해상도를 지원했다. 그리고 동시에 텍스처 4개를 처리할 수 있다. 리얼리티 디스플레이 프로세서는 [[안티 에일리어싱]], 트라이리니어 필터링, 원근 보정(Perspective Correction), 세밀도(Level of Detail), Z버퍼, 안개 효과, 환경 매핑 같은 당시의 플레이스테이션은 물론이고 PC에서도 몇 년 뒤의 부두 칩에서나 나오는 고수준의 3D 기능을 제공했다. 원근 보정 덕분에 플레이스테이션처럼 시점을 변환해도 텍스처가 구겨지지 않는다. 그러나 이런 고급 기능, 특히 Z버퍼 같은 것은 필레이트 성능을 크게 떨어뜨렸다. 또한 텍스처 문제로 개발자들을 괴롭혔다. CPU가 메모리에 접근하려면 GPU를 거쳐야하는 메모리 구조와 램버스 DRAM의 매우 높은 레이턴시 때문에 텍스처는 리얼리티 코프로세서에 내장된 TMEM이라는 4KB 용량의 텍스처 캐시 메모리를 통해 사용해야 했다. 이때문에 텍스처의 용량은 4KB 이내로 맞춰 만들어야 했으며 심지어 닌텐도 64의 기능인 밉맵을 사용하면 그 크기는 2KB로 더 줄어들었다. 이런 문제로 인해 VRAM을 자유롭게 사용할 수 있었던 플레이스테이션보다도 더 저해상도의 텍스처를 사용해야 했으며[* 닌텐도 64의 바이오 하자드 2를 플레이스테이션쪽과 [[https://imgur.com/niEGgRC|텍스처]]를 비교하면 닌텐도쪽 크기가 더 작다.] 여기에 반강제로 걸리는 [[안티 에일리어싱]]과 [[등고선#s-2|컬러 밴딩]] 현상을 완화시키기 위한 디더링 필터로 인해 더욱 흐릿하게 보여질 수 밖에 없었다. 그렇게 텍스처를 적극적으로 사용할 수 없었기 때문에 슈퍼 마리오 64는 동화 분위기라는 점을 이용해 캐릭터 그래픽 구성을 텍스처가 아닌 단색으로 구성한 후 [[렌더링#s-2.1.1.2|고러드 쉐이딩]]을 이용했다. 이후 개발자들은 노하우를 쌓아 텍스처를 회색조로 만들어 단색을 넣는 방식으로 텍스처의 크기를 조금이라도 늘리기도 했고, 사전 계산된 멀티 레이어 텍스처링이나, 작은 텍스처를 이어 붙여 큰 텍스처를 표현하기도 했다. 튜록2 같은 게임은 TMEM보다는 느려도 메모리보다는 빠른 카트리지에서 압축되지 않은 64×64 크기의 텍스처를 직접 불러오기도 했고, 말기에 가서는 팩터5 같은 개발사가 고도의 프로그래밍으로 지속적으로 스트리밍하는 기법까지 만들어졌다. 이때 개발자들에게 받은 불만에 대한 피드백으로 게임큐브에서 텍스처 캐시 메모리를 1MB로 늘렸으며, 빠른 대역폭과 레이턴시를 가진 메모리 시스템인 MoSys의 1T-SRAM 기술을 라이선스 받기도 했다.저장 버튼을 클릭하면 당신이 기여한 내용을 CC-BY-NC-SA 2.0 KR으로 배포하고,기여한 문서에 대한 하이퍼링크나 URL을 이용하여 저작자 표시를 하는 것으로 충분하다는 데 동의하는 것입니다.이 동의는 철회할 수 없습니다.캡챠저장미리보기